home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_5_13.tro < prev    next >
Text File  |  1991-12-22  |  56KB  |  2,638 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ X.229\fR 
  25. .RT
  26. .sp 2P
  27. .sp 1P
  28. .ce 1000
  29. \fBREMOTE\ OPERATIONS:\ PROTOCOL\|
  30. SPECIFICATION\fR 
  31. .FS
  32. Recommendation\ X.229 and ISO\ 9072\(hy2
  33. [Information processing systems \(em
  34. Text Communication \(em Remote Operations Part\ 2: Protocol specification]
  35. were developed in close collaboration and are technically aligned.
  36. .FE
  37. .EF '%    Fascicle\ VIII.5\ \(em\ Rec.\ X.229''
  38. .OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.229    %'
  39. .ce 0
  40. .sp 1P
  41. .ce 1000
  42. \fI(Melbourne, 1988)\fR 
  43. .sp 9p
  44. .RT
  45. .ce 0
  46. .sp 1P
  47. .LP
  48.     The\ CCITT,
  49. .sp 1P
  50. .RT
  51. .sp 1P
  52. .LP
  53. \fIconsidering\fR 
  54. .sp 9p
  55. .RT
  56. .PP
  57. (a)
  58. that Recommendation X.200 defines the Basic Reference Model of Open Systems 
  59. Interconnection (OSI) for CCITT Applications; 
  60. .PP
  61. (b)
  62. that Recommendation X.210 defines the service conventions for describing 
  63. the services of the OSI reference model; 
  64. .PP
  65. (c)
  66. that Recommendation X.216 defines the Presentation Layer
  67. service;
  68. .PP
  69. (d)
  70. that Recommendation X.217 defines the Association Control   service;
  71. .PP
  72. (e)
  73. that Recommendation X.218 defines the Reliable Transfer
  74. service;
  75. .PP
  76. (
  77. f
  78. )
  79. that Recommendation X.219 defines the Remote
  80. Operations service and notation;
  81. .PP
  82. (g)
  83. that there is a need for common Remote Operations support for various applications, 
  84. .sp 1P
  85. .LP
  86. \fIunanimously declares\fR 
  87. .sp 9p
  88. .RT
  89. .PP
  90. that this Recommendation defines the Remote Operations protocol of Open 
  91. Systems Interconnection for CCITT Applications as given in the Scope and 
  92. Field of Application. 
  93. .sp 1P
  94. .ce 1000
  95. CONTENTS
  96. .ce 0
  97. .sp 1P
  98. .sp 2P
  99. .LP
  100. 0
  101.     \fIIntroduction\fR 
  102. .sp 1P
  103. .RT
  104. .sp 1P
  105. .LP
  106. 1
  107.     \fIScope and field of application\fR 
  108. .sp 9p
  109. .RT
  110. .sp 1P
  111. .LP
  112. 2
  113.     \fIReferences\fR 
  114. .sp 9p
  115. .RT
  116. .sp 1P
  117. .LP
  118. 3
  119.     \fIDefinitions\fR 
  120. .sp 9p
  121. .RT
  122. .sp 1P
  123. .LP
  124. 4
  125.     \fIAbbreviations\fR 
  126. .sp 9p
  127. .RT
  128. .sp 1P
  129. .LP
  130. 5
  131.     \fIConventions\fR 
  132. .sp 9p
  133. .RT
  134. .sp 1P
  135. .LP
  136. 6
  137.     \fIOverview of the Protocol\fR 
  138. .sp 9p
  139. .RT
  140. .sp 1P
  141. .LP
  142. 7
  143.     \fIElements of procedure\fR 
  144. .sp 9p
  145. .RT
  146. .sp 1P
  147. .LP
  148. 8
  149.     \fIMapping to used services\fR 
  150. .sp 9p
  151. .RT
  152. .sp 1P
  153. .LP
  154. 9
  155.     \fIConformance\fR 
  156. .sp 9p
  157. .RT
  158. .sp 1P
  159. .LP
  160. 10
  161.     \fIConformance\fR 
  162. .sp 9p
  163. .RT
  164. .sp 1P
  165. .LP
  166. \fIAnnex\ A\fR     \(em
  167.     ROPM State Tables
  168. .sp 9p
  169. .RT
  170. .sp 1P
  171. .LP
  172. \fIAnnex\ B\fR     \(em
  173.     Differences between this Recommendation
  174. and Recommendation\ X.410\(hy1984
  175. .sp 9p
  176. .RT
  177. .sp 1P
  178. .LP
  179. \fIAnnex\ C\fR     \(em
  180.     Summary of assigned object identifier values
  181. .sp 9p
  182. .RT
  183. .LP
  184. .sp 1
  185. .bp
  186. .sp 2P
  187. .LP
  188. \fB0\fR     \fBIntroduction\fR 
  189. .sp 1P
  190. .RT
  191. .PP
  192. This Recommendation specifies the protocol for the services
  193. provided by an application\(hyservice\(hyelement \(em\ the Remote Operations 
  194. Service 
  195. Element (ROSE)\ \(em to support interactive applications in a distributed open
  196. systems environment. This Recommendation is one of a set of Recommendations
  197. defining sets of application\(hyservice\(hyelements commonly used by a 
  198. number of 
  199. applications.
  200. .PP
  201. Interactions between entities of a distributed application are modeled 
  202. as Remote Operations, and defined using a Remote Operations Notation. A 
  203. Remote Operation is requested by one entity; the other entity attempts 
  204. to perform the Remote Operation and then reports the outcome of the attempt. 
  205. Remote Operations are supported by the ROSE. 
  206. .PP
  207. This Recommendation is technically aligned with ISO 9072\(hy2.
  208. .RT
  209. .sp 2P
  210. .LP
  211. \fB1\fR     \fBScope and field of application\fR 
  212. .sp 1P
  213. .RT
  214. .PP
  215. This Recommendation specifies the protocol (abstract syntax) and
  216. procedures for the Remote Operation Service Element (Recommendation\ X.219). 
  217. The ROSE services are provided in conjunction with the Association Control 
  218. Service Element (ACSE) services (Recommendation\ X.217) and the ACSE protocol 
  219. (Recommendation\ X.227), optionally the Reliable Transfer Service Element 
  220. (RTSE) services (Recommendation\ X.218) and the RTSE protocol (Recommendation\ 
  221. X.228), and the presentation\(hyservice (Recommendation\ X.216). 
  222. .PP
  223. The ROSE procedures are defined in terms of:
  224. .RT
  225. .LP
  226.     a)
  227.      the interactions between peer ROSE protocol machines through the use 
  228. of RTSE services or the presentation\(hyservice; 
  229. .LP
  230.     b)
  231.     the interactions between the ROSE protocol machine and its   service\(hyuser.
  232. .PP
  233. This Recommendation specifies conformance requirements for systems implementing 
  234. these procedures. 
  235. .sp 2P
  236. .LP
  237. \fB2\fR     \fBReferences\fR 
  238. .sp 1P
  239. .RT
  240. .LP
  241. Recommendation\ X.200\ \(em
  242.      Reference model of open systems interconnection for CCITT applications 
  243. (see also ISO\ 7498). 
  244. .LP
  245. Recommendation\ X.208\ \(em
  246.     Specification of abstract syntax notation (see also   ISO\ 8824).
  247. .LP
  248. Recommendation\ X.209\ \(em
  249.     Specification of basic encoding rules for the
  250. abstract syntax notation (see also ISO\ 8825).
  251. .LP
  252. Recommendation\ X.210\ \(em
  253.      Open systems interconnection layer service definition conventions (see 
  254. also ISO/TR\ 8509). 
  255. .LP
  256. Recommendation\ X.216\ \(em
  257.     Presentation service definition for open systems
  258. interconnection for CCITT applications (see also ISO\ 8822).
  259. .LP
  260. Recommendation\ X.217\ \(em
  261.     Association control service definition for CCITT
  262. applications (see also ISO\ 8649).
  263. .LP
  264. Recommendation\ X.218\ \(em
  265.     Reliable transfer: model and service definition (see  also ISO\ 9066\(hy1).
  266. .LP
  267. Recommendation\ X.219\ \(em
  268.     Remote operations: model, notation and service
  269. definition (see also ISO\ 9072\(hy1).
  270. .LP
  271. Recommendation\ X.227\ \(em
  272.      Association control protocol specification for CCITT applications (see 
  273. also ISO\ 8650). 
  274. .LP
  275. Recommendation\ X.228\ \(em
  276.     Reliable transfer: protocol specfication (see also
  277. ISO\ 9066\(hy2).
  278. .sp 2P
  279. .LP
  280. \fB3\fR     \fBDefinitions\fR 
  281. .sp 1P
  282. .RT
  283. .sp 1P
  284. .LP
  285. 3.1
  286.     \fIReference model definitions\fR 
  287. .sp 9p
  288. .RT
  289. .PP
  290. This Recommendation is based on the concepts developed in
  291. Recommendation\ X.200 amd makes use of the following terms defined in
  292. it:
  293. .RT
  294. .LP
  295.     a)
  296.     application layer;
  297. .LP
  298.     b)
  299.     application\(hyprocess;
  300. .LP
  301.     c)
  302.     application\(hyentity;
  303. .LP
  304.     d)
  305.     application\(hyservice\(hyelement;
  306. .LP
  307.     e)
  308.     application\(hyprotocol\(hydata\(hyunit;
  309. .bp
  310. .LP
  311.     f
  312. )
  313.     application\(hyprotocol\(hycontrol\(hyinformation;
  314. .LP
  315.     g)
  316.     presentation\(hyservice;
  317. .LP
  318.     h)
  319.     presentation\(hyconnection;
  320. .LP
  321.     i)
  322.     session\(hyservice;
  323. .LP
  324.     j
  325. )
  326.     session\(hyconnection;
  327. .LP
  328.     k)
  329.     transfer syntax; and
  330. .LP
  331.     l)
  332.     user\(hyelement.
  333. .sp 1P
  334. .LP
  335. 3.2
  336.     \fIService conventions definitions\fR 
  337. .sp 9p
  338. .RT
  339. .PP
  340. This Recommendation makes use of the following terms defined in
  341. Recommendation\ X.210:
  342. .RT
  343. .LP
  344.     a)
  345.     service\(hyprovider;
  346. .LP
  347.     b)
  348.     service\(hyuser;
  349. .LP
  350.     c)
  351.     confirmed service;
  352. .LP
  353.     d)
  354.     non\(hyconfirmed service;
  355. .LP
  356.     e)
  357.     provider\(hyinitiated service;
  358. .LP
  359.     f
  360. )
  361.     primitive;
  362. .LP
  363.     g)
  364.     request (primitive);
  365. .LP
  366.     h)
  367.     indication (primitive);
  368. .LP
  369.     i)
  370.     response (primitive); and
  371. .LP
  372.     j
  373. )
  374.     confirm (primitive).
  375. .sp 1P
  376. .LP
  377. 3.3
  378.     \fIPresentation service definitions\fR 
  379. .sp 9p
  380. .RT
  381. .PP
  382. This Recommendation makes use of the following terms defined in
  383. Recommendation\ X.216:
  384. .RT
  385. .LP
  386.     a)
  387.     abstract syntax;
  388. .LP
  389.     b)
  390.     abstract syntax name;
  391. .LP
  392.     c)
  393.     presentation context.
  394. .sp 1P
  395. .LP
  396. 3.4
  397.     \fIAssociation control definitions\fR 
  398. .sp 9p
  399. .RT
  400. .PP
  401. This Recommendation makes use of the following terms defined in
  402. Recommendation\ X.217:
  403. .RT
  404. .LP
  405.     a)
  406.     application\(hyassociation; association;
  407. .LP
  408.     b)
  409.     application context;
  410. .LP
  411.     c)
  412.     association control service element.
  413. .sp 1P
  414. .LP
  415. 3.4
  416.     \fIReliable transfer definitions\fR 
  417. .sp 9p
  418. .RT
  419. .PP
  420. This Recommendation makes use of the following terms defined in
  421. Recommendation\ X.218:
  422. .RT
  423. .LP
  424.     a)
  425.     reliable transfer service element.
  426. .sp 1P
  427. .LP
  428. 3.6
  429.     \fIROSE service definitions\fR 
  430. .sp 9p
  431. .RT
  432. .PP
  433. This Recommendation makes use of the following terms defined in
  434. Recommendation\ X.219:
  435. .RT
  436. .LP
  437.     a)
  438.     association\(hyinitiating\(hyapplication\(hyentity;
  439. association\(hyinitiator;
  440. .LP
  441.     b)
  442.     association\(hyresponding\(hyapplication\(hyentity;
  443. association\(hyresponder;
  444. .LP
  445.     c)
  446.     invoking\(hyapplication\(hyentity; invoker;
  447. .LP
  448.     d)
  449.     performing\(hyapplication\(hyentity; performer;
  450. .LP
  451.     e)
  452.     requestor;
  453. .LP
  454.     f
  455. )
  456.     acceptor;
  457. .LP
  458.     g)
  459.     linked\(hyoperations;
  460. .LP
  461.     h)
  462.     parent\(hyoperation;
  463. .LP
  464.     i)
  465.     child\(hyoperation;
  466. .LP
  467.     j
  468. )
  469.     RO\(hynotation;
  470. .bp
  471. .LP
  472.     k)
  473.     remote operation service element;
  474. .LP
  475.     l)
  476.     ROSE\(hyprovider;
  477. .LP
  478.     m)
  479.     ROSE\(hyuser;
  480. .LP
  481.     n)
  482.     RTSE\(hyuser;
  483. .LP
  484.     o)
  485.     remote operations.
  486. .sp 1P
  487. .LP
  488. 3.7
  489.     \fIRemote operation protocol specification definitions\fR 
  490. .sp 9p
  491. .RT
  492. .PP
  493. For the purpose of this Recommendation the following definitions
  494. apply:
  495. .RT
  496. .sp 1P
  497. .LP
  498. 3.7.1
  499.     \fBremote\(hyoperation\(hyprotocol\(hymachine\fR :
  500. .sp 9p
  501. .RT
  502. .PP
  503. The protocol machine for the remote operation service element
  504. specified in this Recommendation.
  505. .RT
  506. .sp 1P
  507. .LP
  508. 3.7.2
  509.     \fBrequesting\(hyremote\(hyoperation\(hyprotocol\(hymachine\fR :
  510. .sp 9p
  511. .RT
  512. .PP
  513. The remote\(hyoperation\(hyprotocol\(hymachine whose service\(hyuser is the
  514. requestor of a particular remote operation service element service.
  515. .RT
  516. .sp 1P
  517. .LP
  518. 3.7.3
  519.     \fBaccepting\(hyremote\(hyoperation\(hyprotocol\(hymachine\fR :
  520. .sp 9p
  521. .RT
  522. .PP
  523. The remote\(hyoperation\(hyprotocol\(hymachine whose service\(hyuser is the
  524. acceptor for a particular remote operation service element service.
  525. .RT
  526. .sp 2P
  527. .LP
  528. \fB4\fR     \fBAbbreviations\fR 
  529. .sp 1P
  530. .RT
  531. .sp 1P
  532. .LP
  533. 4.1
  534.     \fIData units\fR 
  535. .sp 9p
  536. .RT
  537. .LP
  538.     APDU
  539.     application\(hyprotocol\(hydata\(hyunit.
  540. .sp 1P
  541. .LP
  542. 4.2
  543.     \fITypes of application\(hyprotocol\(hydata\(hyunits\fR 
  544. .sp 9p
  545. .RT
  546. .PP
  547. The following abbreviations have been given to the
  548. application\(hyprotocol\(hydata\(hyunits defined in this Recommendation.
  549. .RT
  550. .LP
  551.     ROIV
  552.     RO\(hyINVOKE application\(hyprotocol\(hydata\(hyunit
  553. .LP
  554.     RORS
  555.     RO\(hyRESULT application\(hyprotocol\(hydata\(hyunit
  556. .LP
  557.     ROER
  558.     RO\(hyERROR application\(hyprotocol\(hydata\(hyunit
  559. .LP
  560.     RORJ
  561.     RO\(hyREJECT application\(hyprotocol\(hydata\(hyunit
  562. .sp 1P
  563. .LP
  564. 4.3
  565.     \fIOther abbreviations\fR 
  566. .sp 9p
  567. .RT
  568. .PP
  569. The following abbreviations are used in this
  570. Recommendation.
  571. .RT
  572. .LP
  573.     AE
  574.     application entiry
  575. .LP
  576.     ACSE
  577.     association control service element
  578. .LP
  579.     ASE
  580.     application service element
  581. .LP
  582.     RO (or ROS)
  583.     remote operations
  584. .LP
  585.     ROPM
  586.     remote operations protocol machine
  587. .LP
  588.     ROSE
  589.     remote operations service element
  590. .LP
  591.     RT
  592.     reliable transfer
  593. .LP
  594.     RTSE
  595.     reliable transfer service element
  596. .bp
  597. .sp 2P
  598. .LP
  599. \fB5\fR     \fBConventions\fR 
  600. .sp 1P
  601. .RT
  602. .PP
  603. This Recommendation employs a tabular presentation of its APDU
  604. fields. In clause\ 7, tables are presented for each ROSE APDU. Each field is
  605. summarized using the following notation:
  606. .RT
  607. .LP
  608.     M
  609.     presence is mandatory
  610. .LP
  611.     U
  612.     presence is a ROSE\(hyuser option
  613. .LP
  614.     req
  615.     source is related request primitive
  616. .LP
  617.     ind
  618.     sink is related indication primitive
  619. .LP
  620.     resp
  621.     source is related response primitive
  622. .LP
  623.     conf
  624.     sink is related confirm primitive
  625. .LP
  626.     sp
  627.     source or sink is the ROPM
  628. .PP
  629. The structure of each ROSE APDU is specified in clause 9 using the abstract 
  630. syntax notation of Recommendation\ X.208. 
  631. .sp 2P
  632. .LP
  633. \fB6\fR     \fBOverview of the protocol\fR 
  634. .sp 1P
  635. .RT
  636. .sp 1P
  637. .LP
  638. 6.1
  639.     \fIService provision\fR 
  640. .sp 9p
  641. .RT
  642. .PP
  643. The protocol specified in Recommendation provides the ROSE services defined 
  644. in Recommendation\ X.219. These services are listed in 
  645. Table\ 1/X.229.
  646. .RT
  647. .LP
  648. .rs
  649. .sp 12P
  650. .ad r
  651. \fBTable 1/X.229 [T1.229], p.\fR 
  652. .sp 1P
  653. .RT
  654. .ad b
  655. .RT
  656. .LP
  657. .sp 1
  658. .sp 1P
  659. .LP
  660. 6.2
  661.     \fIUse of services\fR 
  662. .sp 9p
  663. .RT
  664. .PP
  665. The ROSE protocol specified in this Recommendation needs a transfer service 
  666. to pass information in the form of ROSE APDUs between peer 
  667. application\(hyentities (AEs).
  668. .PP
  669. Two transfer services may be used alternatively:
  670. .RT
  671. .LP
  672.     a)
  673.     the RTSE services, if the RTSE is included in the
  674. application\(hycontext; or
  675. .LP
  676.     b)
  677.      the presentation\(hyservice, if the RTSE is not included in the application\(hycontext. 
  678. .PP
  679. In both cases, an existing application\(hyassociation, established
  680. and released by means of the ACSE services, is assumed.
  681. .sp 1P
  682. .LP
  683. 6.2.1
  684.     \fIUse of the RTSE services\fR 
  685. .sp 9p
  686. .RT
  687. .PP
  688. If the RTSE is included in the application\(hycontext, this
  689. Recommendation assumes that the ROPM is the sole user of the RT\(hyTRANSFER
  690. service and the RT\(hyTURN\(hyGIVE service.
  691. .bp
  692. .PP
  693. The initiating AE may only request the release of the
  694. application\(hyassociation by means of the RT\(hyCLOSE service if it possesses 
  695. the 
  696. turn. Therefore the RTSE\(hyuser and the ROPM are the user of the RT\(hyTURN\(hyPLEASE 
  697. service. 
  698. .PP
  699. The ROPM is the user of the RT\(hyU\(hyABORT and RT\(hyP\(hyABORT services.
  700. .RT
  701. .sp 1P
  702. .LP
  703. 6.2.2
  704.     \fIUse of the presentation\(hyservice\fR 
  705. .sp 9p
  706. .RT
  707. .PP
  708. If the RTSE is not included in the application context, the ROPM is a user 
  709. of the P\(hyDATA service. 
  710. .RT
  711. .sp 1P
  712. .LP
  713. 6.3
  714.     \fIModel\fR 
  715. .sp 9p
  716. .RT
  717. .PP
  718. The remote\(hyoperation\(hyprotocol\(hymachine (ROPM) communicates with 
  719. its service\(hyuser by means of primitives defined in Recommendation\ X.219. 
  720. Each 
  721. invocation of the ROPM controls a single application\(hyassociation.
  722. .PP
  723. The ROPM is driven by ROSE service request primitives from its
  724. service\(hyuser, and by indication and confirm primitives of the RTSE services, 
  725. or the presentation\(hyservice. The ROPM, in turn, issues indication primitives 
  726. to 
  727. its service\(hyuser, and request primitives on the used RTSE services, or the
  728. presentation\(hyservice. If the RTSE is included in the application\(hycontext, 
  729. the RT\(hyTRANSFER indication, RT\(hyTRANSFER request and RT\(hyTRANSFER 
  730. confirm primitives are used. In the case of an application\(hycontext excluding 
  731. RTSE, the 
  732. presentation\(hyservice P\(hyDATA request, and P\(hyDATA indication primitives 
  733. are used. In this case the transfer is not confirmed. 
  734. .PP
  735. The reception of an ROSE service primitive, or of an RTSE service or of 
  736. a presentation\(hyservice primitive, and the generation of dependent actions 
  737. are considered to be individual.
  738. .PP
  739. During the exchange of APDUs, the existence of both, the
  740. association\(hyinitiating\ AE and the association\(hyresponding\ AE is 
  741. presumed. How 
  742. these AEs are created is beyond the scope of this Recommendation.
  743. .PP
  744. During the execution of operations, the existence of an
  745. application\(hyassociation between the peer AEs is presumed. How this
  746. application\(hyassociation is established and released is beyond the scope 
  747. of this Recommendation (see Recommendations\ X.219, X.217, X.227, X.218 
  748. and X.228). 
  749. .PP
  750. \fINote\fR \ \(em\ Each application\(hyassociation may be identified in an end
  751. system by an internal, implementation dependent mechanism so that the ROSE
  752. service\(hyuser and the ROPM can refer to it.
  753. .RT
  754. .sp 2P
  755. .LP
  756. \fB7\fR     \fBElements of procedure\fR 
  757. .sp 1P
  758. .RT
  759. .PP
  760. The ROSE protocol consists of the following elements of
  761. procedure:
  762. .RT
  763. .LP
  764.     a)
  765.     invocation;
  766. .LP
  767.     b)
  768.     return\(hyresult;
  769. .LP
  770.     c)
  771.     return\(hyerror;
  772. .LP
  773.     d)
  774.     user\(hyreject;
  775. .LP
  776.     e)
  777.     provider\(hyreject.
  778. .PP
  779. In the following clauses, a summary of each of these elements of procedure 
  780. is presented. This consists of a summary of the relevant APDUs, and high\(hylevel 
  781. overview of the relationship between the ROSE service primitives, 
  782. the APDUs involved, and the transfer service that is used.
  783. .PP
  784. The generic terms transfer service, transfer service\(hyprovider,
  785. transfer request, and transfer indication are used in the context of clause\ 
  786. 7. Clause\ 8 describes how these generic service primitives are mapped 
  787. either on to the RTSE services or the presentation\(hyservice. 
  788. .PP
  789. In clause 9 a detailed specification of the ROSE APDUs is given using the 
  790. notation defined in Recommendation\ X.208. 
  791. .RT
  792. .sp 2P
  793. .LP
  794. 7.1
  795.     \fIInvocation\fR 
  796. .sp 1P
  797. .RT
  798. .sp 1P
  799. .LP
  800. 7.1.1
  801.     \fIPurpose\fR 
  802. .sp 9p
  803. .RT
  804. .PP
  805. The invocation procedure is used by one AE (the invoker) to request an 
  806. operation to be performed by the other AE (the performer). 
  807. .bp
  808. .RT
  809. .sp 1P
  810. .LP
  811. 7.1.2
  812.     \fIAPDUs used\fR 
  813. .sp 9p
  814. .RT
  815. .PP
  816. The invocation procedure uses the RO\(hyINVOKER (ROIV) APDU.
  817. .PP
  818. The fields of the ROIV APDU are listed in Table 2/X.229.
  819. .RT
  820. .LP
  821. .rs
  822. .sp 11P
  823. .ad r
  824. \fBTable 2/X.229 [T2.229], p.\fR 
  825. .sp 1P
  826. .RT
  827. .ad b
  828. .RT
  829. .sp 1P
  830. .LP
  831. 7.1.3
  832.     \fIInvocation procedure\fR 
  833. .sp 9p
  834. .RT
  835. .PP
  836. This procedure is driven by the following events:
  837. .RT
  838. .LP
  839.     a)
  840.     an RO\(hyINVOKE request primitive from the requestor;
  841. .LP
  842.     b)
  843.     an ROIV APDU as user\(hydata of a transfer indication
  844. primitive.
  845. .sp 1P
  846. .LP
  847. 7.1.3.1
  848.     \fIRO\(hyINVOKE request primitive\fR 
  849. .sp 9p
  850. .RT
  851. .PP
  852. The requesting ROPM forms an ROIV APDU from the parameter values of the 
  853. RO\(hyINVOKE request primitive. It issues a transfer request primitive. 
  854. The 
  855. user\(hydata parameter of the transfer request primitive contains the ROIV 
  856. APDU. 
  857. .PP
  858. The requesting ROPM waits either for a transfer indication primitive from 
  859. the transfer service\(hyprovider or any other primitive from the 
  860. requestor.
  861. .RT
  862. .sp 1P
  863. .LP
  864. 7.1.3.2
  865.     \fIROIV APDU\fR 
  866. .sp 9p
  867. .RT
  868. .PP
  869. The accepting ROPM receives an ROIV APDU from its peer as user\(hydata 
  870. on a transfer indication primitive. If any of the fields of the ROIV APDU 
  871. are unacceptable to this ROPM, the provider\(hyreject procedure is performed, 
  872. and no RO\(hyINVOKE indication primitive is issued by the ROPM. 
  873. .PP
  874. If the ROIV APDU is acceptable to the accepting ROPM, it issues an
  875. RO\(hyINVOKE indication primitive to the acceptor. The RO\(hyINVOKE indication
  876. primitive parameters are derived from the ROIV APDU.
  877. .PP
  878. The accepting ROPM waits either for a transfer indication primitive
  879. from the transfer service\(hyprovider or any other primitive from the
  880. acceptor.
  881. .RT
  882. .sp 1P
  883. .LP
  884. 7.1.4
  885.     \fIUse of the ROIV APDU fields\fR 
  886. .sp 9p
  887. .RT
  888. .PP
  889. The ROIV fields are used as follows.
  890. .RT
  891. .sp 1P
  892. .LP
  893. 7.1.4.1
  894.     \fIInvoke\(hyID\fR 
  895. .sp 9p
  896. .RT
  897. .PP
  898. This is the Invoke\(hyID parameter value of the RO\(hyINVOKE request
  899. primitive. It appears as the Invoke\(hyID parameter value of the RO\(hyINVOKE
  900. indication primitive.
  901. .PP
  902. The value of this field is transparent to the ROPM, however the value may 
  903. be used in the provider reject procedure. 
  904. .bp
  905. .RT
  906. .sp 1P
  907. .LP
  908. 7.1.4.2
  909.     \fILinked\(hyID\fR 
  910. .sp 9p
  911. .RT
  912. .PP
  913. This is the Linked\(hyID parameter value of the RO\(hyINVOKE request
  914. primitive. It appears as the Linked\(hyID parameter value of the RO\(hyINVOKE
  915. indication primitive.
  916. .PP
  917. The value of this field is transparent to the ROPM.
  918. .RT
  919. .sp 1P
  920. .LP
  921. 7.1.4.3
  922.     \fIOperation\(hyvalue\fR 
  923. .sp 9p
  924. .RT
  925. .PP
  926. This is the Operation\(hyvalue parameter value of the RO\(hyINVOKE
  927. request primitive. It appears as the Operation\(hyvalue parameter value of the
  928. RO\(hyINVOKE indication primitive.
  929. .PP
  930. The value of this field is transparent to the ROPM.
  931. .RT
  932. .sp 1P
  933. .LP
  934. 7.1.4.4
  935.     \fIArgument\fR 
  936. .sp 9p
  937. .RT
  938. .PP
  939. This is the Argument parameter value of the RO\(hyINVOKE request
  940. primitive. It appears as the Argument parameter value of the RO\(hyINVOKE
  941. indication primitive.
  942. .PP
  943. The value of this field is transparent to the ROPM.
  944. .RT
  945. .sp 2P
  946. .LP
  947. 7.2
  948.     \fIReturn\(hyresult\fR 
  949. .sp 1P
  950. .RT
  951. .sp 1P
  952. .LP
  953. 7.2.1
  954.     \fIPurpose\fR 
  955. .sp 9p
  956. .RT
  957. .PP
  958. The return\(hyresult procedure is used by one AE (the performer) to
  959. request the transfer of the result of a successfully performed operation 
  960. to the other AE (the invoker). 
  961. .RT
  962. .sp 1P
  963. .LP
  964. 7.2.2
  965.     \fIAPDUs used\fR 
  966. .sp 9p
  967. .RT
  968. .PP
  969. The return\(hyresult procedure uses the RO\(hyRESULT (RORS) APDU.
  970. .PP
  971. The fields of the RORS APDU are listed in Table 3/X.229.
  972. .RT
  973. .LP
  974. .rs
  975. .sp 9P
  976. .ad r
  977. \fBTable 3/X.229 [T3.229], p.\fR 
  978. .sp 1P
  979. .RT
  980. .ad b
  981. .RT
  982. .sp 1P
  983. .LP
  984. 7.2.3
  985.     \fIReturn\(hyresult procedure\fR 
  986. .sp 9p
  987. .RT
  988. .PP
  989. This procedure is driven by the following events:
  990. .RT
  991. .LP
  992.     a)
  993.     an RO\(hyRESULT request primitive from the requestor;
  994. .LP
  995.     b)
  996.     an RORS APDU are user\(hydata of a transfer indication
  997. primitive.
  998. .sp 1P
  999. .LP
  1000. 7.2.3.1
  1001.     \fIRO\(hyRESULT request primitive\fR 
  1002. .sp 9p
  1003. .RT
  1004. .PP
  1005. The requesting ROPM forms an RORS APDU from the parameter values of the 
  1006. RO\(hyRESULT request primitive. It issues a transfer request primitive. 
  1007. The 
  1008. user\(hydata parameter of the transfer request primitive contains the RORS 
  1009. APDU. 
  1010. .PP
  1011. The requesting ROPM waits either for a transfer indication primitive from 
  1012. the transfer service\(hyprovider or any other primitive from the 
  1013. requestor.
  1014. .bp
  1015. .RT
  1016. .sp 1P
  1017. .LP
  1018. 7.2.3.2
  1019.     \fIRORS APDU\fR 
  1020. .sp 9p
  1021. .RT
  1022. .PP
  1023. The accepting ROPM receives an RORS APDU from its peer as user\(hydata 
  1024. on a transfer indication primitive. If any of the fields of the RORS APDU 
  1025. are unacceptable to this ROPM, the provider\(hyreject procedure is performed, 
  1026. and no RO\(hyRESULT indication primitive is issued by the ROPM. 
  1027. .PP
  1028. If the RORS APDU is acceptable to the accepting ROPM, it issues an
  1029. RO\(hyRESULT indication primitive to the acceptor. The RO\(hyRESULT indication
  1030. primitive parameters are derived from the RORS APDU.
  1031. .PP
  1032. The accepting ROPM waits either for a transfer primitive from the
  1033. transfer service\(hyprovider or any other primitive from the acceptor.
  1034. .RT
  1035. .sp 1P
  1036. .LP
  1037. 7.2.4
  1038.     \fIUse of the RORS APDU fields\fR 
  1039. .sp 9p
  1040. .RT
  1041. .PP
  1042. The RORS fields are used as follows.
  1043. .RT
  1044. .sp 1P
  1045. .LP
  1046. 7.2.4.1
  1047.     \fIInvoke\(hyID\fR 
  1048. .sp 9p
  1049. .RT
  1050. .PP
  1051. This is the Invoke\(hyID parameter value of the RO\(hyRESULT request
  1052. primitive. It appears as the Invoke\(hyID parameter value of the RO\(hyRESULT
  1053. indication primitive.
  1054. .PP
  1055. The value of this field is transparent to the ROPM, however the value may 
  1056. be used in the provider\(hyreject procedure. 
  1057. .RT
  1058. .sp 1P
  1059. .LP
  1060. 7.2.4.2
  1061.     \fIOperation\(hyvalue\fR 
  1062. .sp 9p
  1063. .RT
  1064. .PP
  1065. This is the Operation\(hyvalue parameter value of the RO\(hyRESULT
  1066. request primitive. It appears as the Operation\(hyvalue parameter value of the
  1067. RO\(hyRESULT indication primitive.
  1068. .PP
  1069. The value of this field is transparent to the ROPM.
  1070. .PP
  1071. This field shall be present only if the result field is present.
  1072. .RT
  1073. .sp 1P
  1074. .LP
  1075. 7.2.4.3
  1076.     \fIResult\fR 
  1077. .sp 9p
  1078. .RT
  1079. .PP
  1080. This is the Result parameter value of the RO\(hyRESULT request
  1081. primitive. It appears as the Result parameter value of the RO\(hyRESULT
  1082. indication primitive.
  1083. .PP
  1084. The value of this field is transparent to the ROPM.
  1085. .RT
  1086. .sp 2P
  1087. .LP
  1088. 7.3
  1089.     \fIReturn\(hyerror\fR 
  1090. .sp 1P
  1091. .RT
  1092. .sp 1P
  1093. .LP
  1094. 7.3.1
  1095.     \fIPurpose\fR 
  1096. .sp 9p
  1097. .RT
  1098. .PP
  1099. The return\(hyerror procedure is used by one AE (the performer) to
  1100. request the transfer of the error information in the case of an unsuccessfully 
  1101. performed operation to the other AE (the invoker). 
  1102. .RT
  1103. .sp 1P
  1104. .LP
  1105. 7.3.2
  1106.     \fIAPDUs used\fR 
  1107. .sp 9p
  1108. .RT
  1109. .PP
  1110. The return\(hyerror procedure uses the RO\(hyERROR (ROER) APDU.
  1111. .PP
  1112. The fields of the ROER APDU are listed in Table 4/X.229.
  1113. .RT
  1114. .LP
  1115. .rs
  1116. .sp 9P
  1117. .ad r
  1118. \fBTable 4/X.229 [T4.229], p.\fR 
  1119. .sp 1P
  1120. .RT
  1121. .ad b
  1122. .RT
  1123. .LP
  1124. .bp
  1125. .sp 1P
  1126. .LP
  1127. 7.3.3
  1128.     \fIReturn\(hyerror procedure\fR 
  1129. .sp 9p
  1130. .RT
  1131. .PP
  1132. This procedure is driven by the following events:
  1133. .RT
  1134. .LP
  1135.     a)
  1136.     an RO\(hyERROR request primitive from the requestor;
  1137. .LP
  1138.     b)
  1139.     an ROER APDU as user\(hydata of a transfer indication
  1140. primitive.
  1141. .sp 1P
  1142. .LP
  1143. 7.3.3.1
  1144.     \fIRO\(hyERROR request primitive\fR 
  1145. .sp 9p
  1146. .RT
  1147. .PP
  1148. The requesting ROPM forms an ROER APDU from the parameter values of the 
  1149. RO\(hyERROR request primitive. It issues a transfer request primitive. 
  1150. The 
  1151. user\(hydata parameter of the transfer request primitive contains the ROER 
  1152. APDU. 
  1153. .PP
  1154. The requesting ROPM waits either for a transfer primitive from the
  1155. transfer service\(hyprovider or any other primitive from the requestor.
  1156. .RT
  1157. .sp 1P
  1158. .LP
  1159. 7.3.3.2
  1160.     \fIROER APDU\fR 
  1161. .sp 9p
  1162. .RT
  1163. .PP
  1164. The accepting ROPM receives an ROER APDU from its peer as user\(hydata 
  1165. on a transfer indication primitive. If any of the fields of the ROER APDU 
  1166. are unacceptable to this ROPM, the provider\(hyreject procedure is performed, 
  1167. and no RO\(hyERROR indication primitive is issued by the ROPM. 
  1168. .PP
  1169. If the ROER APDU is acceptable to the accepting ROPM, it issues an
  1170. RO\(hyERROR indication primitive to the acceptor. The RO\(hyERROR indication
  1171. primitive parameters are derived from the ROER APDU.
  1172. .PP
  1173. The accepting ROPM waits either for a transfer indication primitive
  1174. from the transfer service\(hyprovider or any other primitive from the
  1175. acceptor.
  1176. .RT
  1177. .sp 1P
  1178. .LP
  1179. 7.3.4
  1180.     \fIUse of the ROER APDU fields\fR 
  1181. .sp 9p
  1182. .RT
  1183. .PP
  1184. The ROER fields are used as follows.
  1185. .RT
  1186. .sp 1P
  1187. .LP
  1188. 7.3.4.1
  1189.     \fIInvoke\(hyID\fR 
  1190. .sp 9p
  1191. .RT
  1192. .PP
  1193. This is the Invoke\(hyID parameter value of the RO\(hyERROR request
  1194. primitive. It appears as the Invoke\(hyID parameter value of the RO\(hyERROR
  1195. indication primitive.
  1196. .PP
  1197. The value of this field is transparent to the ROPM, however the value may 
  1198. be used in the provider\(hyreject procedure. 
  1199. .RT
  1200. .sp 1P
  1201. .LP
  1202. 7.3.4.2
  1203.     \fIError\(hyvalue\fR 
  1204. .sp 9p
  1205. .RT
  1206. .PP
  1207. This is the Error\(hyvalue parameter value of the RO\(hyERROR
  1208. request primitive. It appears as the Error\(hyvalue parameter value of the
  1209. RO\(hyERROR indication primitive.
  1210. .PP
  1211. The value of this field is transparent to the ROPM.
  1212. .RT
  1213. .sp 1P
  1214. .LP
  1215. 7.3.4.3
  1216.     \fIError\(hyparameter\fR 
  1217. .sp 9p
  1218. .RT
  1219. .PP
  1220. This is the Error\(hyparameter parameter value of the RO\(hyERROR
  1221. request primitive. It appears as the Error\(hyparameter parameter value of the
  1222. RO\(hyERROR indication primitive.
  1223. .PP
  1224. The value of this field is transparent to the ROPM.
  1225. .bp
  1226. .RT
  1227. .sp 2P
  1228. .LP
  1229. 7.4
  1230.     \fIUser\(hyreject\fR 
  1231. .sp 1P
  1232. .RT
  1233. .sp 1P
  1234. .LP
  1235. 7.4.1
  1236.     \fIPurpose\fR 
  1237. .sp 9p
  1238. .RT
  1239. .PP
  1240. The user\(hyreject procedure is used by one AE to reject the request (invocation) 
  1241. or reply (result or error) of the other AE. 
  1242. .RT
  1243. .sp 1P
  1244. .LP
  1245. 7.4.2
  1246.     \fIAPDUs used\fR 
  1247. .sp 9p
  1248. .RT
  1249. .PP
  1250. The user\(hyreject procedure uses the RO\(hyREJECT (RORJ) APDU. This
  1251. RORJ APDU is used in addition by the provider\(hyreject procedure.
  1252. .PP
  1253. The fields of the RORJ APDU used for the user\(hyreject procedure are
  1254. listed in Table\ 5/X.229.
  1255. .RT
  1256. .LP
  1257. .rs
  1258. .sp 12P
  1259. .ad r
  1260. \fBTable 5/X.229 [T5.229], p.\fR 
  1261. .sp 1P
  1262. .RT
  1263. .ad b
  1264. .RT
  1265. .sp 1P
  1266. .LP
  1267. 7.4.3
  1268.     \fIUser\(hyreject procedure\fR 
  1269. .sp 9p
  1270. .RT
  1271. .PP
  1272. This procedure is driven by the following events:
  1273. .RT
  1274. .LP
  1275.     a)
  1276.     an RO\(hyREJECT\(hyU request primitive from the requestor;
  1277. .LP
  1278.     b)
  1279.     an RORJ APDU as user\(hydata of a transfer indication
  1280. primitive.
  1281. .sp 1P
  1282. .LP
  1283. 7.4.3.1
  1284.     \fIRO\(hyREJECT\(hyU request primitive\fR 
  1285. .sp 9p
  1286. .RT
  1287. .PP
  1288. The requesting ROPM forms an RORJ APDU from the parameter values of the 
  1289. RO\(hyREJECT\(hyU request primitive. It issues a transfer request primitive. 
  1290. The user\(hydata parameter of the transfer request primitive contains the 
  1291. RORJ APDU. 
  1292. .PP
  1293. The requesting ROPM waits either for a transfer indication primitive from 
  1294. the transfer service\(hyprovider or any other primitive from the 
  1295. acceptor.
  1296. .RT
  1297. .sp 1P
  1298. .LP
  1299. 7.4.3.2
  1300.     \fIRORJ APDU\fR 
  1301. .sp 9p
  1302. .RT
  1303. .PP
  1304. The accepting ROPM receives an RORJ APDU from its peer as user\(hydata 
  1305. on a transfer indication primitive. If any of the fields of the RORJ APDU 
  1306. are unacceptable to this ROPM, no RO\(hyREJECT\(hyU indication primitive 
  1307. is issued by the ROPM. 
  1308. .PP
  1309. If the RORJ APDU is acceptable to the accepting ROPM and the fields of 
  1310. the RORJ APDU indicates a user reject (i.e.\ Invoke\(hyproblem, 
  1311. Return\(hyresult\(hyproblem, or Return\(hyerror\(hyproblem), it issues 
  1312. an RO\(hyREJECT\(hyU 
  1313. indication primitive to the acceptor. The RO\(hyREJECT\(hyU indication 
  1314. primitive 
  1315. parameters (Invoke\(hyID and Reject\(hyreason) are derived from the RORJ APDU.
  1316. .PP
  1317. The accepting ROPM waits either for a transfer indication primitive
  1318. from the transfer service\(hyprovider or any other primitive from the
  1319. acceptor.
  1320. .bp
  1321. .RT
  1322. .sp 1P
  1323. .LP
  1324. 7.4.4
  1325.     \fIUse of the RORJ APDU fields\fR 
  1326. .sp 9p
  1327. .RT
  1328. .PP
  1329. The RORJ fields are used as follows.
  1330. .RT
  1331. .sp 1P
  1332. .LP
  1333. 7.4.4.1
  1334.     \fIInvoke\(hyID\fR 
  1335. .sp 9p
  1336. .RT
  1337. .PP
  1338. This is the Invoke\(hyID parameter value of the RO\(hyREJECT\(hyU request
  1339. primitive. It appears as the Invoke\(hyID parameter value of the RO\(hyREJECT\(hyU 
  1340. indication primitive.
  1341. .PP
  1342. The value of this field is transparent to the ROPM.
  1343. .RT
  1344. .sp 1P
  1345. .LP
  1346. 7.4.4.2
  1347.     \fIProblem\fR 
  1348. .sp 9p
  1349. .RT
  1350. .PP
  1351. This is the Problem parameter value of the RO\(hyREJECT\(hyU request
  1352. primitive. It appears as the Problem parameter value of the RO\(hyREJECT\(hyU
  1353. indication primitive.
  1354. .PP
  1355. The values used by the user\(hyreject procedure are:
  1356. .RT
  1357. .LP
  1358.     a)
  1359.     \fIInvoke problem\fR :\ user\(hyreject of an RO\(hyINVOKE indication
  1360. primitive with values:
  1361. .LP
  1362.     \(em
  1363.     duplicate\(hyinvocation:
  1364. .LP
  1365.     signifies that the Invoke\(hyID parameter violates the
  1366. assignment rules of Recommendation\ X.219.
  1367. .LP
  1368.     \(em
  1369.     unrecognized\(hyoperation:
  1370. .LP
  1371.     signifies that the operation is not one of those
  1372. agreed between the ROSE\(hyusers.
  1373. .LP
  1374.     \(em
  1375.     mistyped\(hyargument:
  1376. .LP
  1377.     signifies that the type of the operation argument
  1378. supplied is not that agreed between the ROSE\(hyusers
  1379. .LP
  1380.     \(em
  1381.     resource\(hylimitation:
  1382. .LP
  1383.     the performing ROSE\(hyuser is not able to perform the
  1384. invoked operation due to resource limitation.
  1385. .LP
  1386.     \(em
  1387.     initiator\(hyreleasing:
  1388. .LP
  1389.     the association\(hyinitiator is not willing to perform
  1390. the invoked operation because it is about to attempt to release the
  1391. application\(hyassociation.
  1392. .LP
  1393.     \(em
  1394.     unrecognized\(hylinked\(hyID:
  1395. .LP
  1396.      signifies that there is no operation in progress with an Invoke\(hyID 
  1397. equal to the specified Linked\(hyID. 
  1398. .LP
  1399.     \(em
  1400.     linked\(hyresponse\(hyunexpected:
  1401. .LP
  1402.     signifies that the invoked operation referred to by
  1403. the Link\(hyID is not a parent\(hyoperation.
  1404. .LP
  1405.     \(em
  1406.     unexpected\(hychild\(hyoperation:
  1407. .LP
  1408.      signifies that the invoked child\(hyoperation is not one that the invoked 
  1409. parent\(hyoperation referred to by the Linked\(hyID allows. 
  1410. .LP
  1411.     b)
  1412.     \fIReturn\(hyresult\(hyproblem\fR :\ user\(hyreject of an RO\(hyRESULT
  1413. indication primitive with values:
  1414. .LP
  1415.     \(em
  1416.     unrecognized\(hyinvocation:
  1417. .LP
  1418.     signifies that no operation with the specified
  1419. Invoke\(hyID is in progress.
  1420. .LP
  1421.     \(em
  1422.     result\(hyresponse\(hyunexpected:
  1423. .LP
  1424.     signifies that the invoked operation does not report a result.
  1425. .LP
  1426.     \(em
  1427.     mistyped\(hyresult:
  1428. .LP
  1429.     signifies that the type of the Result parameter
  1430. supplied is not that agreed between the ROSE\(hyusers.
  1431. .LP
  1432.     c)
  1433.     \fIReturn\(hyerror\(hyproblem\fR :\ user\(hyreject of an RO\(hyERROR
  1434. indication primitive with values:
  1435. .LP
  1436.     \(em
  1437.     unrecognized\(hyinvocation:
  1438. .LP
  1439.     signifies that no operation with the specified
  1440. Invoke\(hyID is in progress
  1441. .LP
  1442.     \(em
  1443.     error\(hyresponse\(hyunexpected:
  1444. .LP
  1445.     signifies that the invoked operation does not report   failure
  1446. .LP
  1447.     \(em
  1448.     unrecognized\(hyerror:
  1449. .LP
  1450.      signifies that the reported error is not one of those agreed between 
  1451. the ROSE\(hyusers 
  1452. .bp
  1453. .LP
  1454.     \(em
  1455.     unexpected\(hyerror:
  1456. .LP
  1457.      signifies that the reported error is not one that the invoked operation 
  1458. may report 
  1459. .LP
  1460.     \(em
  1461.     mistyped\(hyparameter:
  1462. .LP
  1463.     signifies that the type of the error parameter
  1464. supplied is not that agreed between the ROSE\(hyusers.
  1465. .sp 2P
  1466. .LP
  1467. 7.5
  1468.     \fIProvider\(hyreject\fR 
  1469. .sp 1P
  1470. .RT
  1471. .sp 1P
  1472. .LP
  1473. 7.5.1
  1474.     \fIPurpose\fR 
  1475. .sp 9p
  1476. .RT
  1477. .PP
  1478. The provider\(hyreject procedure is used to inform the ROSE user and the 
  1479. peer ROPM, if an ROPM detects a problem. 
  1480. .RT
  1481. .sp 1P
  1482. .LP
  1483. 7.5.2
  1484.     \fIAPDUs used\fR 
  1485. .sp 9p
  1486. .RT
  1487. .PP
  1488. The provider\(hyreject procedure uses the RO\(hyREJECT (RORJ) APDU. This 
  1489. RORJ APDU is used in addition by the user\(hyreject procedure. 
  1490. .PP
  1491. The fields of the RORJ APDU used for the provider\(hyreject procedure are 
  1492. listed in Table\ 6/X.229. 
  1493. .RT
  1494. .LP
  1495. .rs
  1496. .sp 9P
  1497. .ad r
  1498. \fBTable 6/X.229 [T6.229], p.\fR 
  1499. .sp 1P
  1500. .RT
  1501. .ad b
  1502. .RT
  1503. .sp 1P
  1504. .LP
  1505. 7.5.3
  1506.     \fIProvider\(hyreject procedure\fR 
  1507. .sp 9p
  1508. .RT
  1509. .PP
  1510. This procedure is driven by the following events:
  1511. .RT
  1512. .LP
  1513.     a)
  1514.     an unacceptable APDU as user\(hydata of a transfer indication   primitive;
  1515. .LP
  1516.     b)
  1517.     an RORJ APDU with the Problem parameter choice
  1518. General\(hyproblem as user\(hydata of a transfer indication primitive;
  1519. .LP
  1520.     c)
  1521.     unsuccessful APDU transfer (e.g. association abort).
  1522. .sp 1P
  1523. .LP
  1524. 7.5.3.1
  1525.     \fIUnacceptable APDU\fR 
  1526. .sp 9p
  1527. .RT
  1528. .PP
  1529. The receiving ROPM receives an APDU from its peer as user data on a transfer 
  1530. indication primitive. If any of the fields of the APDU (except RORJ 
  1531. APDU) are unacceptable to this ROPM, it forms an RORJ APDU with the Problem
  1532. field choice General\(hyproblem and the Invoke\(hyID of the rejected APDU. The
  1533. receiving ROPM issues a transfer request primitive. The user\(hydata parameter 
  1534. of the transfer request primitive contains the RORJ APDU. 
  1535. .PP
  1536. If the received unacceptable APDU is an RORJ APDU no new RORJ APDU is formed 
  1537. and transferred. In this case, or after the rejection of a locally 
  1538. specified number of APDUs, the application\(hyassociation is released abnormally. 
  1539. .PP
  1540. If the application\(hyassociation is not released abnormally, the
  1541. receiving ROPM waits either for a transfer indication primitive from the
  1542. transfer service\(hyprovider or any other primitive from the requestor.
  1543. .bp
  1544. .RT
  1545. .sp 1P
  1546. .LP
  1547. 7.5.3.2
  1548.     \fIRORJ APDU\fR 
  1549. .sp 9p
  1550. .RT
  1551. .PP
  1552. The receiving ROPM receives an RORJ APDU from its peer as user\(hydata 
  1553. on a transfer indication primitive. If any of the fields of the RORJ APDU 
  1554. are unacceptable to this ROPM, the provider\(hyreject procedure for an 
  1555. unacceptable 
  1556. APDU is performed.
  1557. .PP
  1558. If the RORJ APDU is acceptable to the accepting ROPM and the Problem field 
  1559. of the RORJ APDU indicates a General\(hyproblem, it issues an RO\(hyREJECT\(hyP 
  1560. indication primitive to the acceptor. The RO\(hyREJECT\(hyP indication 
  1561. primitive 
  1562. parameters (Invoke\(hyID and Reject\(hyreason) are derived from the RORJ APDU.
  1563. .PP
  1564. The receiving ROPM waits either for a transfer indication primitive
  1565. from the transfer service\(hyprovider or any other primitive from the
  1566. acceptor.
  1567. .RT
  1568. .sp 1P
  1569. .LP
  1570. 7.5.3.3
  1571.     \fIUnsuccessful APDU transfer\fR 
  1572. .sp 9p
  1573. .RT
  1574. .PP
  1575. If a sending ROPM is not able to transfer an APDU by means of the transfer 
  1576. request primitive (e.g.\ in the case of abnormal association release), 
  1577. the sending ROPM issues an RO\(hyREJECT\(hyP indication primitive to the 
  1578. requestor 
  1579. for each APDU not yet transferred.
  1580. .PP
  1581. The RO\(hyREJECT\(hyP indication primitive parameter Returned\(hyparameters
  1582. contains the parameters of the RO\(hyINVOKE request, RO\(hyRESULT request, 
  1583. RO\(hyERROR request or RO\(hyREJECT\(hyU request primitives. 
  1584. .PP
  1585. After all Returned\(hyparameters of the APDUs not transferred have been 
  1586. issued to the requestor, the application\(hyassociation, if it still exists, 
  1587. is 
  1588. released abnormally.
  1589. .RT
  1590. .sp 1P
  1591. .LP
  1592. 7.5.4
  1593.     \fIUse of the RORJ APDU fields\fR 
  1594. .sp 9p
  1595. .RT
  1596. .PP
  1597. The RORJ APDU fields are used as follows.
  1598. .RT
  1599. .sp 1P
  1600. .LP
  1601. 7.5.4.1
  1602.     \fIInvoke\(hyID\fR 
  1603. .sp 9p
  1604. .RT
  1605. .PP
  1606. This is the Invoke\(hyID field of a rejected APDU and the Invoke\(hyID
  1607. parameter of the RO\(hyREJECT\(hyP indication primitive. The type and value 
  1608. of this field may be NULL, if the Invoke\(hyID field of the rejected APDU 
  1609. is not 
  1610. detectable. In this case, the Invoke\(hyID parameter of the RO\(hyREJECT\(hyP 
  1611. indication primitive is omitted. 
  1612. .RT
  1613. .sp 1P
  1614. .LP
  1615. 7.5.4.2
  1616.     \fIProblem: General\(hyproblem\fR 
  1617. .sp 9p
  1618. .RT
  1619. .PP
  1620. This is the Problem parameter value of the RO\(hyREJECT\(hyP indication 
  1621. primitive. The values used by the provider\(hyreject procedure are: 
  1622. .RT
  1623. .LP
  1624.     d)
  1625.     \fIGeneral\(hyproblem\fR :\ provider\(hyreject of an APDU with values:
  1626. .LP
  1627.     \(em
  1628.     unrecognized\(hyAPDU:
  1629. .LP
  1630.      signifies that the type of the APDU, as evidenced by its Type Identifier, 
  1631. is not one of the four defined by this Recommendation. 
  1632. .LP
  1633.     \(em
  1634.     mistyped\(hyAPDU:
  1635. .LP
  1636.     signifies that the structure of the APDU does not
  1637. conform to this Recommendation.
  1638. .LP
  1639.     \(em
  1640.     badly\(hystructured\(hyAPDU:
  1641. .LP
  1642.      signifies that the structure of the APDU does not conform to the standard 
  1643. notation and encoding, defined in Recommendations\ X.208 
  1644. and\ X.209.
  1645. .sp 2P
  1646. .LP
  1647. \fB8\fR     \fBMapping to used services\fR 
  1648. .sp 1P
  1649. .RT
  1650. .PP
  1651. This clause defines how an ROPM transfers APDUs by means
  1652. of:
  1653. .RT
  1654. .LP
  1655.     a)
  1656.     the RTSE services, or
  1657. .LP
  1658.     b)
  1659.     the presentation\(hyservice.
  1660. .PP
  1661. Clause 8.1 defines the mapping on the RTSE services, and
  1662. clause 8.2 defines the mapping on the presentation\(hyservice.
  1663. .PP
  1664. Identification of the named abstract syntax in use is assumed for all ROSE 
  1665. services and is mapped onto used services, however this is a local matter 
  1666. and outside the scope of this Recommendation. 
  1667. .bp
  1668. .RT
  1669. .sp 1P
  1670. .LP
  1671. 8.1
  1672.     \fIMapping on the RTSE services\fR 
  1673. .sp 9p
  1674. .RT
  1675. .PP
  1676. This clause defines how RTSE service primitives described in
  1677. Recommendation\ X.218 are used by the ROPM. Table\ 7/X.229 defines the 
  1678. mapping of the ROSE service primitives and APDUs to the RTSE service primitives. 
  1679. .RT
  1680. .LP
  1681. .sp 3
  1682. .rs
  1683. .sp 15P
  1684. .ad r
  1685. \fBTable 7/X.229 [T7.229], p.\fR 
  1686. .sp 1P
  1687. .RT
  1688. .ad b
  1689. .RT
  1690. .LP
  1691. .sp 4
  1692. .sp 1P
  1693. .LP
  1694. 8.1.1
  1695.     \fIManaging the turn\fR 
  1696. .sp 9p
  1697. .RT
  1698. .PP
  1699. A ROPM shall possess the turn before it can use the RT\(hyTRANSFER
  1700. service. The ROPM without the turn may issue a RT\(hyTURN\(hyPLEASE request 
  1701. primitive the priority parameter of which reflects the highest priority 
  1702. APDU awaiting 
  1703. transfer.
  1704. .PP
  1705. The ROPM which has the turn, may issue an RT\(hyTURN\(hyGIVE request
  1706. primitive when it has no further APDUs to transfer. It will issue an
  1707. RT\(hyTURN\(hyGIVE request primitive in response to an RT\(hyTURN\(hyPLEASE 
  1708. indication when it has no further APDUs to transfer of priority equal to 
  1709. or higher than that 
  1710. indicated in the RT\(hyTURN\(hyPLEASE indication primitive. If it has APDUs 
  1711. of lower priority still to transfer, it may issue an RT\(hyTURN\(hyPLEASE 
  1712. request whose 
  1713. priority reflects the highest priority APDU remaining to be transferred.
  1714. .RT
  1715. .sp 1P
  1716. .LP
  1717. 8.1.1.1
  1718.     \fIUse of the RT\(hyTURN\(hyPLEASE service\fR 
  1719. .sp 9p
  1720. .RT
  1721. .PP
  1722. The ROPM issues the RT\(hyTURN\(hyPLEASE request primitive to request the 
  1723. turn. It may do so only if it does not already possess the turn. The 
  1724. RT\(hyTURN\(hyPLEASE service is a non\(hyconfirmed service.
  1725. .PP
  1726. The use of the RT\(hyTURN\(hyPLEASE service parameters is as follows:
  1727. .RT
  1728. .LP
  1729.     Priority: this reflects the highest priority APDU awaiting
  1730. transfer.
  1731. .sp 1P
  1732. .LP
  1733. 8.1.1.2
  1734.     \fIUse of the RT\(hyTURN\(hyGIVE service\fR 
  1735. .sp 9p
  1736. .RT
  1737. .PP
  1738. The ROPM issues the RT\(hyTURN\(hyGIVE request primitive to relinquish
  1739. the turn to its peer. It may do so only if it possesses the turn. The
  1740. RT\(hyTURN\(hyGIVE service is a non\(hyconfirmed service with no parameters.
  1741. .bp
  1742. .RT
  1743. .sp 1P
  1744. .LP
  1745. 8.1.2
  1746.     \fIAPDU transfer\fR 
  1747. .sp 9p
  1748. .RT
  1749. .PP
  1750. Each APDU is transferred as user\(hydata of the RT\(hyTRANSFER service. 
  1751. The ROPM only issues an RT\(hyTRANSFER request primitive, if the ROPM possesses 
  1752. the turn, and if there is no outstanding RT\(hyTRANSFER confirm primitive.
  1753. .RT
  1754. .sp 1P
  1755. .LP
  1756. 8.1.2.1
  1757.     \fIUse of the RT\(hyTRANSFER service\fR 
  1758. .sp 9p
  1759. .RT
  1760. .PP
  1761. The RT\(hyTRANSFER service is a confirmed service.
  1762. .PP
  1763. The use of the RT\(hyTRANSFER request primitive parameters is as
  1764. follows:
  1765. .RT
  1766. .LP
  1767.     APDU
  1768. .LP
  1769.      The APDU to be transferred. Its maximum size is not restricted in this 
  1770. mapping. 
  1771. .LP
  1772.     Transfer\(hytime
  1773. .LP
  1774.      This is specified by a local rule of the sending ROPM. It may be related 
  1775. to the priority of the APDU. 
  1776. .PP
  1777. The use of the RT\(hyTRANSFER indication primitive parameters is as   follows:
  1778. .LP
  1779.     APDU
  1780. .LP
  1781.     The APDU transferred. Its maximum size is not restricted in this   mapping.
  1782. .PP
  1783. The use of the RT\(hyTRANSFER confirm primitive parameters is as
  1784. follows:
  1785. .LP
  1786.     APDU
  1787. .LP
  1788.      The APDU not transferred within the Transfer\(hytime. This parameter 
  1789. is only provided, if the value of the Result parameter is 
  1790. \*QAPDU\(hynot\(hytransferred\*U. In this case the ROPM issues a RO\(hyREJECT\(hyP 
  1791. indication primitive with the parameter Returned\(hyparameters. 
  1792. .LP
  1793.     Result
  1794. .LP
  1795.     The parameter value \*QAPDU\(hytransferred\*U indicates a positive
  1796. confirm, the parameter value \*QAPDU\(hynot\(hytransferred\*U indicates 
  1797. a negative 
  1798. confirm.
  1799. .sp 1P
  1800. .LP
  1801. 8.2
  1802.     \fIMapping on the presentation\(hyservice\fR 
  1803. .sp 9p
  1804. .RT
  1805. .PP
  1806. This clause defines how the presentation\(hyservice primitives
  1807. described in Recommendation\ X.216 are used by the ROPM. Table\ 8/X.229 
  1808. defines the mapping of the ROSE service primitives and APDUs to the 
  1809. presentation\(hyservice primitives.
  1810. .RT
  1811. .LP
  1812. .sp 2
  1813. .rs
  1814. .sp 13P
  1815. .ad r
  1816. \fBTable 8/X.229 [T8.229], p.\fR 
  1817. .sp 1P
  1818. .RT
  1819. .ad b
  1820. .RT
  1821. .LP
  1822. .bp
  1823. .sp 1P
  1824. .LP
  1825. 8.2.1
  1826.     \fIAPDU transfer\fR 
  1827. .sp 9p
  1828. .RT
  1829. .PP
  1830. Each APDU is transferred as user\(hydata of the P\(hyDATA service.
  1831. .RT
  1832. .sp 1P
  1833. .LP
  1834. 8.2.1.1
  1835.     \fIUse of the P\(hyDATA service\fR 
  1836. .sp 9p
  1837. .RT
  1838. .PP
  1839. The P\(hyDATA service is a non\(hyconfirmed service.
  1840. .PP
  1841. The use of the P\(hyDATA request and P\(hyDATA indication primitive
  1842. parameters is as follows:
  1843. .RT
  1844. .LP
  1845.     User Data
  1846. .LP
  1847.      The APDU to be transferred. Its maximum size is not restricted in this 
  1848. mapping. 
  1849. .sp 2P
  1850. .LP
  1851. \fB9\fR     \fBAbstract syntax definition of APDUs\fR 
  1852. .sp 1P
  1853. .RT
  1854. .PP
  1855. The abstract syntax of each ROSE APDU is specified in this clause using 
  1856. the abstract syntax notation of Recommendation\ X.208 and is shown in 
  1857. Figure\ 1/X.229.
  1858. .RT
  1859. .LP
  1860. .rs
  1861. .sp 32P
  1862. .ad r
  1863. \fBFigure 1/X.229 [T9.229], p.9 \ \ 
  1864. (\*`a traiter comme tableau MEP)\fR 
  1865. .sp 1P
  1866. .RT
  1867. .ad b
  1868. .RT
  1869. .LP
  1870. .bp
  1871. .LP
  1872. .rs
  1873. .sp 47P
  1874. .ad r
  1875. \fBFigure 1/X.229 [T10.229], p.10 \ \ 
  1876. (\*`a traiter comme tableau MEP)\fR 
  1877. .sp 1P
  1878. .RT
  1879. .ad b
  1880. .RT
  1881. .LP
  1882. .bp
  1883. .LP
  1884. .rs
  1885. .sp 34P
  1886. .ad r
  1887. \fBFigure 1/X.229 [T11.229], p.11 \ \ 
  1888. (\*`a traiter comme tableau MEP)\fR 
  1889. .sp 1P
  1890. .RT
  1891. .ad b
  1892. .RT
  1893. .sp 2P
  1894. .LP
  1895. \fB10\fR     \fBConformance\fR 
  1896. .sp 1P
  1897. .RT
  1898. .PP
  1899. An implementation claiming conformance to this Recommendation shall comply 
  1900. with the requirements in clauses\ 10.1 through 10.3. 
  1901. .RT
  1902. .sp 1P
  1903. .LP
  1904. 10.1
  1905.     \fIStatement requirements\fR 
  1906. .sp 9p
  1907. .RT
  1908. .PP
  1909. An implementor shall state the following:
  1910. .RT
  1911. .LP
  1912.     a)
  1913.     the application context for which conformance is claimed,
  1914. including whether the system supports the mapping of ROSE onto RTSE, onto 
  1915. the presentation\(hyservice, or both. 
  1916. .sp 1P
  1917. .LP
  1918. 10.2
  1919.     \fIStatic requirements\fR 
  1920. .sp 9p
  1921. .RT
  1922. .PP
  1923. The system shall:
  1924. .RT
  1925. .LP
  1926.     a)
  1927.     conform to the abstract syntax definition of APDUs defined   in clause\ 9.
  1928. .sp 1P
  1929. .LP
  1930. 10.3
  1931.     \fIDynamic requirements\fR 
  1932. .sp 9p
  1933. .RT
  1934. .PP
  1935. The system shall:
  1936. .RT
  1937. .LP
  1938.     a)
  1939.     conform to the elements of procedure defined in clause 7,
  1940. .LP
  1941.     b)
  1942.     conform to the mappings to the used services, for which
  1943. conformance is claimed, as defined in clause\ 8.
  1944. \v'1P'
  1945. .bp
  1946. .ce 1000
  1947. ANNEX\ A
  1948. .ce 0
  1949. .ce 1000
  1950. (to Recommendation X.229)
  1951. .sp 9p
  1952. .RT
  1953. .ce 0
  1954. .ce 1000
  1955. \fBROPM state tables\fR 
  1956. .sp 1P
  1957. .RT
  1958. .ce 0
  1959. .PP
  1960. This Annex forms an integral Part of this Recommendation.
  1961. .sp 1P
  1962. .RT
  1963. .sp 1P
  1964. .LP
  1965. A.1
  1966.     \fIGeneral\fR 
  1967. .sp 9p
  1968. .RT
  1969. .PP
  1970. This Annex defines a single Remote Operations Protocol Machine
  1971. (ROPM) in terms of a state table. The state table shows the interrelationship 
  1972. between the state of an application\(hyassociation, the incoming events 
  1973. that occur in the protocol, the actions taken, and, finally the resultant 
  1974. state of the 
  1975. application\(hyassociation.
  1976. .PP
  1977. The ROPM state table does not constitute a formal definition of the
  1978. ROPM. It is included to provide a more precise specification of the elements 
  1979. of procedure defined in clauses\ 7 and\ 8. 
  1980. .PP
  1981. This Annex contains the following tables:
  1982. .RT
  1983. .LP
  1984.     a)
  1985.      Table A\(hy1/X.229 specifies the abbreviated name, source, and name/description 
  1986. of each incoming event. The sources are: 
  1987. .LP
  1988.     1)
  1989.     ROSE\(hyuser (ROSE\(hyuser);
  1990. .LP
  1991.     2)
  1992.     peer ROPM (ROPM\(hypeer);
  1993. .LP
  1994.     3)
  1995.     ROPM excluding the transfer part (ROPM);
  1996. .LP
  1997.     4)
  1998.     transfer part of the ROPM (ROPM\(hyTR);
  1999. .LP
  2000.     5)
  2001.      either Presentation service\(hyprovider (PS\(hyprovider) and the Association 
  2002. Control Service Element (ACSE), or the Reliable Transfer 
  2003. Service Element (RTSE).
  2004. .LP
  2005.     b)
  2006.     Table A\(hy2/X.229 specifies the abbreviated name of each state of the ROPM.
  2007. .LP
  2008.     c)
  2009.      Table A\(hy3/X.229 specifies the abbreviated name of each state of the 
  2010. ROPM\(hyTR. 
  2011. .LP
  2012.     d)
  2013.      Table A\(hy4/X.229 specifies the abbreviated name, target, and name/description 
  2014. of each outgoing event. The targets are: 
  2015. .LP
  2016.     1)
  2017.     ROSE\(hyuser (ROSE\(hyuser);
  2018. .LP
  2019.     2)
  2020.     peer ROPM (RPOM peer);
  2021. .LP
  2022.     3)
  2023.     ROPM excluding the transfer part (ROPM);
  2024. .LP
  2025.     4)
  2026.     transfer part of the ROPM (ROPM\(hyTR); and
  2027. .LP
  2028.     5)
  2029.      either Presentation service\(hyprovider (PS\(hyprovider) and the Association 
  2030. Control Service Element (ACSE), or the Reliable Transfer 
  2031. Service Element (RTSE).
  2032. .LP
  2033.     e)
  2034.     Table A\(hy5/X.229 specifies the predicates.
  2035. .LP
  2036.     f
  2037. )
  2038.      Table A\(hy6/X.229 specifies the ROPM state table using the abbreviations 
  2039. of the above tables. 
  2040. .LP
  2041.     g)
  2042.      Table A\(hy7/X.229 specifies the ROPM\(hyTR state table using the abbreviations 
  2043. of the above tables, if the RTSE is included in the application context. 
  2044. .LP
  2045.     h)
  2046.      Table A\(hy8/X.229 specifies the ROPM\(hyTR state table using the abbreviations 
  2047. of the above tables, if the RTSE is not included in the 
  2048. application context.
  2049. .sp 1P
  2050. .LP
  2051. A.2
  2052.     \fIConventions\fR 
  2053. .sp 9p
  2054. .RT
  2055. .PP
  2056. The intersection of an incoming event (row) and a state (column)
  2057. forms a cell.
  2058. .PP
  2059. In the state table, a blank cell represents the combination of an
  2060. incoming event and a state that is not defined for the ROPM. (See A.3.1.)
  2061. .PP
  2062. A non\(hyblank cell represents an incoming event and a state that is
  2063. defined for the ROPM. Such a cell contains one or more action lists. An 
  2064. action list may be either mandatory or conditional. If a cell contains 
  2065. a mandatory 
  2066. action list, it is the only action list in the cell.
  2067. .PP
  2068. A mandatory action list contains:
  2069. .RT
  2070. .LP
  2071.     a)
  2072.     optionally one or more outgoing events, and
  2073. .LP
  2074.     b)
  2075.     a resultant state.
  2076. .bp
  2077. .PP
  2078. A conditional action list contains:
  2079. .LP
  2080.     a)
  2081.     a predicate expression comprising predicates and Boolean
  2082. operators (\ \ 
  2083. represents the Boolean NOT), and
  2084. .LP
  2085.     b)
  2086.      a mandatory action list (this mandatory action list is used only if the 
  2087. predicate expression is true). 
  2088. .sp 1P
  2089. .LP
  2090. A.3
  2091.     \fIActions to be taken by the ROPM\fR 
  2092. .sp 9p
  2093. .RT
  2094. .PP
  2095. The ROPM state table defines the action to be taken by the ROPM in terms 
  2096. of an optional outgoing event and the resultant state of the 
  2097. application\(hyassociation.
  2098. .RT
  2099. .sp 1P
  2100. .LP
  2101. A.3.1
  2102.     \fIInvalid intersections\fR 
  2103. .sp 9p
  2104. .RT
  2105. .PP
  2106. Blank cells indicate an invalid intersection of an incoming event and state. 
  2107. If such an intersection occurs, one of the following actions is 
  2108. taken:
  2109. .RT
  2110. .LP
  2111.     a)
  2112.      If the incoming event comes from the ROSE\(hyuser, any action taken by 
  2113. the ROPM is a local matter. 
  2114. .LP
  2115.     b)
  2116.     If the incoming event is related to a received APDU,
  2117. PS\(hyprovider, ACSE, or RTSE; either the ROPM issues an AA\(hyABreq event 
  2118. to the 
  2119. ROPM\(hyTR, or the ROPM\(hyTR issues an ABORTreq to either the RTSE or 
  2120. ACSE and an 
  2121. AA\(hyABind to the ROPM.
  2122. .sp 1P
  2123. .LP
  2124. A.3.2
  2125.     \fIValid intersections\fR 
  2126. .sp 9p
  2127. .RT
  2128. .PP
  2129. If the intersection of the state and incoming event is valid, one of the 
  2130. following actions is taken: 
  2131. .RT
  2132. .LP
  2133.     a)
  2134.      If the cell contains a mandatory action list, the ROPM takes the action 
  2135. specified. 
  2136. .LP
  2137.     b)
  2138.      If a cell contains one or more conditional action lists, for each predicate 
  2139. expression that is true, the ROPM takes the actions specified. If none 
  2140. of the predicate expressions are true, the ROPM takes one of the 
  2141. actions defined in \(sc\ A.3.1.
  2142. .LP
  2143. .rs
  2144. .sp 29P
  2145. .ad r
  2146. BLANC
  2147. .ad b
  2148. .RT
  2149. .LP
  2150. .bp
  2151. .LP
  2152. .rs
  2153. .sp 43P
  2154. .ad r
  2155. \fBTableau A\(hy1/X.229 [T12.229], p.12\fR 
  2156. .ad b
  2157. .RT
  2158. .LP
  2159. \-v'1P'
  2160. \-v'6p'
  2161. .rs
  2162. .sp 8P
  2163. .ad r
  2164. \fBTableau A\(hy2/X.229 [T14.229], p.13\fR 
  2165. .ad b
  2166. .RT
  2167. .LP
  2168. .bp
  2169. .LP
  2170. .rs
  2171. .sp 14P
  2172. .ad r
  2173. \fBTableau A\(hy3/X.229 [T15.229], p.14\fR 
  2174. .sp 1P
  2175. .RT
  2176. .ad b
  2177. .RT
  2178. .LP
  2179. .rs
  2180. .sp 32P
  2181. .ad r
  2182. \fBTableau A\(hy4/X.229 [T16.229], p.15\fR 
  2183. .sp 1P
  2184. .RT
  2185. .ad b
  2186. .RT
  2187. .LP
  2188. .bp
  2189. .LP
  2190. .rs
  2191. .sp 9P
  2192. .ad r
  2193. \fBTableau A\(hy5/X.229 [T17.229], p.16\fR 
  2194. .sp 1P
  2195. .RT
  2196. .ad b
  2197. .RT
  2198. .LP
  2199. .rs
  2200. .sp 37P
  2201. .ad r
  2202. \fBTableau A\(hy6/X.229 [T18.229], p.17\fR 
  2203. .sp 1P
  2204. .RT
  2205. .ad b
  2206. .RT
  2207. .LP
  2208. .bp
  2209. .LP
  2210. .rs
  2211. .sp 32P
  2212. .ad r
  2213. \fBTableau A\(hy7/X.229 [T19.229], p.18\fR 
  2214. .ad b
  2215. .RT
  2216. .LP
  2217. \-v'1P'
  2218. \-v'6p'
  2219. .rs
  2220. .sp 19P
  2221. .ad r
  2222. \fBTableau A\(hy8/X.229 [T20.229], p.19\fR 
  2223. .ad b
  2224. .RT
  2225. .LP
  2226. .bp
  2227. .ce 1000
  2228. ANNEX\ B
  2229. .ce 0
  2230. .ce 1000
  2231. (to Recommendation X.229)
  2232. .sp 9p
  2233. .RT
  2234. .ce 0
  2235. .ce 1000
  2236. \fBDifferences between this Recommendation\fR 
  2237. .sp 1P
  2238. .RT
  2239. .ce 0
  2240. .ce 1000
  2241. \fBand Recommendation X.410\(hy1984\fR 
  2242. .ce 0
  2243. .PP
  2244. This Annex is not an integral Part of this Recommendation.
  2245. .sp 1P
  2246. .RT
  2247. .PP
  2248. This Annex describes the technical differences between the
  2249. notation
  2250. and protocol for Remote Operations of this Recommendation and the corresponding 
  2251. notation and protocol of Recommendation\ X.410\(hy1984. 
  2252. .sp 2P
  2253. .LP
  2254. B.1
  2255.     \fIMacros\fR 
  2256. .sp 1P
  2257. .RT
  2258. .sp 1P
  2259. .LP
  2260. B.1.1
  2261.     \fINew Macros\fR 
  2262. .sp 9p
  2263. .RT
  2264. .LP
  2265.     1)
  2266.     \fIAdd\fR \|:
  2267.     BIND macro and UNBIND macro
  2268. .sp 1P
  2269. .LP
  2270. B.1.2
  2271.     \fIOPERATION Macro\fR 
  2272. .sp 9p
  2273. .RT
  2274. .LP
  2275.     1)
  2276.     Value Notation
  2277. .LP
  2278.     \fIChange\fR \|: From:
  2279.     INTEGER
  2280.     \ \ To:
  2281.     CHOICE
  2282.     {
  2283.     INTEGER,
  2284.     OBJECT IDENTIFIER}
  2285. .LP
  2286.     2)
  2287.     Named Type in Result production
  2288. .LP
  2289.     \fIChange\fR \|: From:
  2290.     mandatory
  2291.     \ \ To:
  2292.     optional
  2293. .LP
  2294.     3)
  2295.     \fIAdd\fR \|:
  2296.     Productions for linked Operations
  2297. .sp 1P
  2298. .LP
  2299. B.1.3
  2300.     \fIERROR Macro\fR 
  2301. .sp 9p
  2302. .RT
  2303. .LP
  2304.     1)
  2305.     Value Notation see B.1.2 item 1.
  2306. .sp 2P
  2307. .LP
  2308. B.2
  2309.     \fIApplication protocol data units\fR 
  2310. .sp 1P
  2311. .RT
  2312. .sp 1P
  2313. .LP
  2314. B.2.1
  2315.     \fIAPDUs\fR 
  2316. .sp 9p
  2317. .RT
  2318. .LP
  2319.     1)
  2320.     Choice alternative
  2321.     \fIChange\fR \|: From:
  2322.     explicit tagging
  2323.     \ \ To:
  2324.     implicit tagging
  2325. .sp 1P
  2326. .LP
  2327. B.2.2
  2328.     \fIInvoke\fR 
  2329. .sp 9p
  2330. .RT
  2331. .LP
  2332.     1)
  2333.     \fIAdd\fR \|:
  2334.     optional linked\(hyID element to SEQUENCE
  2335. .LP
  2336.     2)
  2337.     argument element
  2338.     \fIChange\fR \|: From:
  2339.     mandatory
  2340.     \ \ To:
  2341.     optional
  2342. .sp 1P
  2343. .LP
  2344. B.2.3
  2345.     \fIReturn result\fR 
  2346. .sp 9p
  2347. .RT
  2348. .LP
  2349.     1)
  2350.     \fIAdd\fR \|:
  2351.     Field operation\(hyvalue and SEQUENCE
  2352. .LP
  2353.     2)
  2354.     result element
  2355.     \fIChange\fR \|: From:
  2356.     mandatory
  2357.     \ \ To:
  2358.     optional
  2359. .sp 1P
  2360. .LP
  2361. B.2.4
  2362.     \fIReject\fR 
  2363. .sp 9p
  2364. .RT
  2365. .LP
  2366.     1)
  2367.     Invoke Problem
  2368.     \fIAdd\fR \|:
  2369.     values (3) to (7) inclusive
  2370. .bp
  2371. .sp 2P
  2372. .LP
  2373. B.3
  2374.     \fIProcedures and mapping\fR 
  2375. .sp 1P
  2376. .RT
  2377. .sp 1P
  2378. .LP
  2379. B.3.1
  2380.     \fIMapping onto used services\fR 
  2381. .sp 9p
  2382. .RT
  2383. .LP
  2384.     1)
  2385.     \fIAdd:\fR     Mapping onto Presentation service if RTSE is
  2386. absent in the Application Context
  2387. .LP
  2388.     2)
  2389.     \fIAdd:\fR     Mapping for BIND and UNBIND
  2390. .sp 1P
  2391. .LP
  2392. B.4
  2393.     \fIInterworking between 84 and 88 implementation\fR 
  2394. .sp 9p
  2395. .RT
  2396. .PP
  2397. Due to B.2.1 item 1 and B.2.3 item 1 interworking between 84 and 88 implementations 
  2398. is not possible. However the first change was indicated in the X.400\(hySeries 
  2399. Implementators Guide Version\ 5. 
  2400. \v'2P'
  2401. .RT
  2402. .ce 1000
  2403. ANNEX\ C
  2404. .ce 0
  2405. .ce 1000
  2406. (to Recommendation X.229)
  2407. .sp 9p
  2408. .RT
  2409. .ce 0
  2410. .ce 1000
  2411. \fBSummary of assigned object identifier values\fR 
  2412. .sp 1P
  2413. .RT
  2414. .ce 0
  2415. .PP
  2416. .sp 2
  2417. This Annex is not an integral Part of this Recommendation.
  2418. .sp 1P
  2419. .RT
  2420. .PP
  2421. This Annex summarizes the object identifier values assigned in
  2422. Recommendations X.219 and\ X.229.
  2423. .sp 1P
  2424. .LP
  2425. \fB{\ joint\(hyiso\(hyccitt remote\(hyoperations(4) notation (0)\ }\fR 
  2426. \(em\(em\ \fIASN.1 module defined in X.219\fR 
  2427. .sp 9p
  2428. .RT
  2429. .sp 1P
  2430. .LP
  2431. \fB{\ joint\(hyiso\(hyccitt remote\(hyoperations(4) apdus (1)\ }\fR \(em\(em\ 
  2432. \fIASN.1 module defined in X.229\fR 
  2433. .sp 9p
  2434. .RT
  2435. .sp 1P
  2436. .LP
  2437. \fB{\ joint\(hyiso\(hyccitt remote\(hyoperations(4)
  2438. notation\(hyextensions (2)\ }\fR \(em\(em\ \fIASN.1 module defined dans 
  2439. X.219\fR 
  2440. .sp 9p
  2441. .RT
  2442. .sp 1P
  2443. .LP
  2444. \fB{\ joint\(hyiso\(hyccitt remote\(hyoperations(4) aseiD (3)\ }\fR \(em\(em\ 
  2445. \fIASE identifier defined in X.229\fR 
  2446. .sp 9p
  2447. .RT
  2448. .sp 1P
  2449. .LP
  2450. \fB{\ joint\(hyiso\(hyccitt remote\(hyoperations(4) aseiD\(hyACSE (4)\ 
  2451. }\fR \(em\(em\ \fIASE identifier defined in X.219\fR 
  2452. .sp 9p
  2453. .RT
  2454. .LP
  2455. .rs
  2456. .sp 4P
  2457. .ad r
  2458. BLANC
  2459. .ad b
  2460. .RT
  2461. .LP
  2462. .bp
  2463. .sp 2P
  2464. .LP
  2465. \fBRecommendation\ X.244\fR 
  2466. .RT
  2467. .sp 2P
  2468. .ce 1000
  2469. \fBPROCEDURE\ FOR\ THE\ \fR \fBEXCHANGE\ OF\ PROTOCOL\fR 
  2470. .EF '%    Fascicle\ VIII.5\ \(em\ Rec.\ X.244''
  2471. .OF '''Fascicle\ VIII.5\ \(em\ Rec.\ X.244    %'
  2472. .ce 0
  2473. .ce 1000
  2474. \fBIDENTIFICATION\ DURING\ VIRTUAL\ CALL\ ESTABLISHMENT\fR 
  2475. .ce 0
  2476. .sp 1P
  2477. .ce 1000
  2478. \fBON\ PACKET\ SWITCHED\ PUBLIC\ DATA\ NETWORKS\fR 
  2479. .ce 0
  2480. .sp 1P
  2481. .ce 1000
  2482. \fI(Malaga\(hyTorremolinos, 1984)\fR 
  2483. .sp 9p
  2484. .RT
  2485. .ce 0
  2486. .sp 1P
  2487. .LP
  2488. .sp 1
  2489.     The\ CCITT,
  2490. .sp 1P
  2491. .RT
  2492. .sp 1P
  2493. .LP
  2494. \fIconsidering\fR 
  2495. .sp 9p
  2496. .RT
  2497. .PP
  2498. (a)
  2499. that Recommendation X.25 defines the interface between data terminal equipment 
  2500. (DTE) and data circuit\(hyterminating equipment (DCE) for terminals operating 
  2501. in the packet mode and connected to public data networks by dedicated circuit; 
  2502. .LP
  2503. .PP
  2504. (b)
  2505. that Recommendation X.32 defines the interface between data terminal equipment 
  2506. (DTE) and data circuit\(hyterminating equipment (DCE) for terminals operating 
  2507. in the packet mode and accessing a packet switched public data network 
  2508. through a public switched network; 
  2509. .PP
  2510. (c)
  2511. that Recommendation X.29 defines the procedures for the exchange of control 
  2512. information and user data between a packet 
  2513. assembly/disassembly facility (PAD) and a packet mode DTE or another PAD;
  2514. .PP
  2515. (d)
  2516. that Recommendation X.224 defines the Transport Layer
  2517. Protocol for Open Systems Interconnection for CCITT Applications, which
  2518. includes provision of a Transport Protocol Identification; and
  2519. .PP
  2520. (e)
  2521. that there is a need to identify and/or negotiate at
  2522. virtual call establishment the protocol which is to operate above the packet
  2523. level,
  2524. .LP
  2525. .sp 1P
  2526. .LP
  2527. \fIunanimously recommends\fR 
  2528. .sp 9p
  2529. .RT
  2530. .PP
  2531. that for data terminal equipment operating in the packet mode the mechanism 
  2532. for identification and/or negotiation of the protocol which is to 
  2533. operate above the packet level should be as specified below.
  2534. .RT
  2535. .sp 2P
  2536. .LP
  2537. \fB1\fR     \fBIntroduction\fR 
  2538. .sp 1P
  2539. .RT
  2540. .PP
  2541. This Recommendation defines the procedures for the exchange of
  2542. protocol identification during virtual call establishment on packet switched
  2543. public data networks. This procedure operates above the packet level of
  2544. Recommendation\ X.25. It makes use of bits\ 8 and\ 7 of the first octet of the
  2545. user data field in the call set\(hyup packets defined in Recommendation\ X.25.
  2546. .RT
  2547. .sp 2P
  2548. .LP
  2549. \fB2\fR     \fBCall user data field\fR 
  2550. .sp 1P
  2551. .RT
  2552. .PP
  2553. The following procedure applies to the call user data field of Call Request 
  2554. and Incoming Call packets. 
  2555. .PP
  2556. If the call user data field is present, the use and format of this
  2557. field are determined by bits\ 8 and\ 7 of the first octet of this field 
  2558. (see Note below). 
  2559. .PP
  2560. If bits 8 and 7 of the first octet of the call user data field are\ 00, 
  2561. a portion of the call user data field is used for protocol identification 
  2562. in 
  2563. accordance with other Recommendations such as Recommendation\ X.29 and
  2564. Recommendation\ X.224.
  2565. .bp
  2566. .PP
  2567. If bits 8 and 7 of the first octet of the call user data field are 01, 
  2568. a portion of the call user data field may be used for protocol identification 
  2569. in accordance with specifications of Administrations. 
  2570. .PP
  2571. If bits 8 and 7 of the first octet of the call user data field are 10, 
  2572. a portion of the call user data field may be used for protocol identification 
  2573. in accordance with specifications of international user bodies. 
  2574. .PP
  2575. If bits 8 and 7 of the first octet of the call user data field are 11, 
  2576. no constraints are placed on the use by the DTE of the remainder of the 
  2577. call 
  2578. user data field.
  2579. .PP
  2580. Users are cautioned that if bits 8 and 7 of the first octet of the
  2581. call user data field have any value other than 11, a protocol may be identified 
  2582. that is implemented within public data networks. 
  2583. .PP
  2584. \fINote\fR \ \(em\ When a virtual call is being established between two 
  2585. packet mode DTEs, the network does not act on any part of the call user 
  2586. data 
  2587. field.
  2588. .RT
  2589. .sp 2P
  2590. .LP
  2591. \fB3\fR     \fBCalled user data field\fR 
  2592. .sp 1P
  2593. .RT
  2594. .PP
  2595. The following procedure applies to the called user data field of
  2596. Call Accepted and Call Connected packets used in conjunction with the fast
  2597. select facility.
  2598. .PP
  2599. If the called user data field is present, the use and format of this field 
  2600. is determined by bits 8 and 7 of the first octet of this field (see Note 
  2601. below). 
  2602. .PP
  2603. If bits 8 and 7 of the first octet of the called user data field
  2604. are 00, a portion of the called user data field is used for protocol
  2605. identification in accordance with other Recommendations.
  2606. .PP
  2607. If bits 8 and 7 of the first octet of the called user data field
  2608. are 01, a portion of the called user data field may be used for protocol
  2609. identification in accordance with specifications of Administrations.
  2610. .PP
  2611. If bits 8 and 7 of the first octet of the called user data field
  2612. are 10, a portion of the called user data field may be used for protocol
  2613. identification in accordance with specifications of international user
  2614. bodies.
  2615. .PP
  2616. If bits 8 and 7 of the first octet of the called user data field
  2617. are 11, no constraints are placed on the use by the DTE of the remainder of
  2618. the called user data field.
  2619. .PP
  2620. Users are cautioned that if bits 8 and 7 of the first octet of the
  2621. called user data field have any value other than 11, a protocol may be
  2622. identified that is implemented within public data networks.
  2623. .PP
  2624. \fINote\fR \ \(em\ When a virtual call is being established between two 
  2625. packet mode DTEs, the network does not act on any part of the called user 
  2626. data 
  2627. field.
  2628. .RT
  2629. .LP
  2630. .rs
  2631. .sp 4P
  2632. .ad r
  2633. BLANC
  2634. .ad b
  2635. .RT
  2636. .LP
  2637. .bp
  2638.